Bridge PPL_REX_MAX_MATCH_LIMIT into UnifiedQueryContext on the unified query path by RyanL1997 · Pull Request #5418 · opensearch-project/sql

RyanL1997 · 2026-05-07T21:04:45Z

Description

The PPL rex command's AstBuilder reads Settings.Key.PPL_REX_MAX_MATCH_LIMIT unconditionally and unboxes the result to int. On the unified query path, UnifiedQueryContext builds its Settings map with only a small whitelist of planning-required keys; for any unregistered key, getSettingValue returns null and the auto-unbox NPEs the planner before any operator-level capability check runs. Every rex query through /_analytics/ppl hits this NPE today.

This PR ships two changes that together let the unified path execute rex correctly:

1. Default `PPL_REX_MAX_MATCH_LIMIT=10` in `UnifiedQueryContext`

Adds the key to the static settings map so AstBuilder.visitRexCommand no longer NPEs. The value mirrors the cluster-side default of 10 registered by OpenSearchSettings.PPL_REX_MAX_MATCH_LIMIT_SETTING, so unified-path behavior matches v2-path behavior when neither has an explicit cluster override. Mirrors the precedent Kai introduced for CALCITE_ENGINE_ENABLED in #5413.

2. Bridge live cluster settings for `PPL_REX_MAX_MATCH_LIMIT` only

Without this, every key in the static map resolves to its hardcoded default and _cluster/settings updates are invisible to the unified path. CalciteRexCommandIT.testRexMaxMatchConfigurableLimit exercises this: it sets the cluster-side limit to 5 and asserts that max_match=0 caps at 5, but on the unified path the static 10 keeps winning.

Adds a Builder.liveSettings(Settings) hook so the REST handler can inject the cluster's live OpenSearchSettings instance. At build() time the Builder snapshots the live value of PPL_REX_MAX_MATCH_LIMIT into the static map, overriding the hardcoded default when the operator has set a cluster value. Snapshot-at-build matches the per-HTTP-request lifecycle of UnifiedQueryContext and avoids per-call lookup overhead.

RestUnifiedQueryAction gains a pluginSettings field (the same OpenSearchSettings instance bound in the Guice module) and forwards it to the Builder in both buildContext and buildParsingContext. Both construction sites — SQLPlugin.createSqlAnalyticsRouter and TransportPPLQueryAction.<init> — are updated.

Why scoped to `PPL_REX_MAX_MATCH_LIMIT` only

The same architectural gap exists for every key in the static map (QUERY_SIZE_LIMIT, PPL_SUBSEARCH_MAXOUT, PPL_JOIN_SUBSEARCH_MAXOUT, CALCITE_ENGINE_ENABLED). For three of those, the static defaults are fine in practice (no test overrides them mid-run; head N covers QUERY_SIZE_LIMIT per-query). CALCITE_ENGINE_ENABLED is intentionally pinned to true for the unified path — a cluster override toggling it off would defeat the point of routing here. So this PR widens only the one key that demonstrably needs it; widening the snapshot to the rest is a future scope decision tied to whichever new IT first depends on it.

Companion PR

opensearch-project/OpenSearch#21550 — onboards PPL rex to DataFusion via the analytics-engine path. Without this PR's fixes, every rex query through /_analytics/ppl NPEs at parse time and never reaches the planner.

Test results

CalciteRexCommandIT through the analytics-engine route (every PPL query forced through /_analytics/ppl via tests.analytics.force_routing=true):

Without this PR: 0/18 — every test NPEs in AstBuilder.visitRexCommand.
With change 1 only (default 10): 17/18 — testRexMaxMatchConfigurableLimit fails with expected:<5> but was:<10>.
With both changes: 18/18, 100% — all testRexMaxMatch* variants honor the cluster setting.

Signed-off-by: Jialiang Liang jiallian@amazon.com

github-actions · 2026-05-07T21:05:51Z

PR Reviewer Guide 🔍

(Review updated until commit `aa0ae82`)

Here are some key observations to aid the review process:

🧪 No relevant tests
🔒 No security concerns identified
✅ No TODO sections
🔀 No multiple PR themes
⚡ Recommended focus areas for review Possible Issue `buildParsingContext` now calls `applyClusterOverrides`, which reads from `pluginSettings`. If `buildParsingContext` is invoked before `pluginSettings` is initialized (e.g., during early initialization or from a code path that doesn't set it), accessing `pluginSettings.getSettingValue` will throw a NullPointerException. The old implementation was static and had no such dependency. private UnifiedQueryContext buildParsingContext(QueryType queryType) { return applyClusterOverrides(UnifiedQueryContext.builder().language(queryType)).build(); }

github-actions · 2026-05-07T21:06:02Z

PR Code Suggestions ✨

Latest suggestions up to aa0ae82

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Validate type before using setting value The method retrieves `rexLimit` as `Object` but doesn't validate its type before passing it to `builder.setting()`. If `pluginSettings` returns an unexpected type (e.g., String instead of Integer), this could cause runtime failures downstream when the value is unboxed. Add type validation or casting to ensure `rexLimit` is an `Integer` before using it. plugin/src/main/java/org/opensearch/sql/plugin/rest/RestUnifiedQueryAction.java [184-194] private UnifiedQueryContext.Builder applyClusterOverrides(UnifiedQueryContext.Builder builder) { Object rexLimit = pluginSettings.getSettingValue( org.opensearch.sql.common.setting.Settings.Key.PPL_REX_MAX_MATCH_LIMIT); - if (rexLimit != null) { + if (rexLimit instanceof Integer) { builder.setting( org.opensearch.sql.common.setting.Settings.Key.PPL_REX_MAX_MATCH_LIMIT.getKeyValue(), rexLimit); } return builder; } Suggestion importance[1-10]: 7 __ Why: The suggestion correctly identifies a potential type safety issue where `rexLimit` is retrieved as `Object` and could be an unexpected type. However, the improved code changes the behavior from passing through any non-null value to only passing `Integer` instances, which may be overly restrictive if the setting system guarantees type consistency. The score reflects a valid defensive programming improvement with moderate impact.	Medium

Previous suggestions

Suggestions up to commit c655e4a

Category	Suggestion	Impact
Possible issue	Add type safety for setting value The code retrieves `liveRexLimit` as `Object` but `PPL_REX_MAX_MATCH_LIMIT` expects an `Integer`. If the settings return a different numeric type (e.g., `Long`), this could cause a `ClassCastException` when `getSettingValue` unboxes to `int` in `AstBuilder.visitRexCommand`. Add type validation or safe casting to ensure the value is an `Integer` before inserting it into `defaults`. api/src/main/java/org/opensearch/sql/api/UnifiedQueryContext.java [277-282] if (settings != null) { Object liveRexLimit = settings.getSettingValue(PPL_REX_MAX_MATCH_LIMIT); - if (liveRexLimit != null) { + if (liveRexLimit instanceof Integer) { defaults.put(PPL_REX_MAX_MATCH_LIMIT, liveRexLimit); } } Suggestion importance[1-10]: 7 __ Why: The suggestion correctly identifies a potential type safety issue where `liveRexLimit` is retrieved as `Object` and could cause a `ClassCastException` if it's not an `Integer`. However, this is primarily a defensive programming improvement rather than a critical bug, as the settings system likely returns the correct type. The score reflects its value as a safety enhancement.	Medium

Suggestions up to commit 6d0dc2c

Category	Suggestion	Impact
Possible issue	Add type validation for setting value The code retrieves `liveRexLimit` as `Object` but doesn't validate its type before inserting into the settings map. If `getSettingValue` returns an unexpected type (e.g., String instead of Integer), this could cause runtime failures when the value is later unboxed to `int` in `AstBuilder.visitRexCommand`. Add type validation or safe casting to ensure the value is an Integer before insertion. api/src/main/java/org/opensearch/sql/api/UnifiedQueryContext.java [261-266] if (liveSettings != null) { Object liveRexLimit = liveSettings.getSettingValue(PPL_REX_MAX_MATCH_LIMIT); - if (liveRexLimit != null) { + if (liveRexLimit instanceof Integer) { settings.put(PPL_REX_MAX_MATCH_LIMIT, liveRexLimit); } } Suggestion importance[1-10]: 7 __ Why: The suggestion correctly identifies a potential type safety issue where `liveRexLimit` is retrieved as `Object` and could be an unexpected type. Adding `instanceof Integer` check prevents runtime failures during unboxing. However, the PR context shows this is a controlled setting value that should already be typed correctly, making this a defensive improvement rather than fixing a critical bug.	Medium
General	Validate pluginSettings parameter for null The constructor accepts `pluginSettings` but doesn't validate it for null. Since `buildParsingContext` and `buildContext` methods call `liveSettings(pluginSettings)` without null checks, a null `pluginSettings` parameter could lead to unexpected behavior. Add null validation in the constructor to fail fast with a clear error message. plugin/src/main/java/org/opensearch/sql/plugin/rest/RestUnifiedQueryAction.java [64-73] public RestUnifiedQueryAction( NodeClient client, ClusterService clusterService, QueryPlanExecutor<RelNode, Iterable<Object[]>> planExecutor, org.opensearch.sql.common.setting.Settings pluginSettings) { this.client = client; this.clusterService = clusterService; this.analyticsEngine = new AnalyticsExecutionEngine(planExecutor); - this.pluginSettings = pluginSettings; + this.pluginSettings = Objects.requireNonNull(pluginSettings, "pluginSettings cannot be null"); } Suggestion importance[1-10]: 6 __ Why: The suggestion adds defensive null checking for `pluginSettings` parameter. While this improves robustness, the PR shows `pluginSettings` is always instantiated before being passed to the constructor (in `SQLPlugin.java` and `TransportPPLQueryAction.java`), making null unlikely. The null check in `build()` method (line 261) already handles null `liveSettings` gracefully, so this is a minor defensive improvement.	Low

Suggestions up to commit e46eaa0

Category	Suggestion	Impact
Possible issue	Add type validation before storing setting The code retrieves `liveRexLimit` as `Object` and puts it directly into the settings map without type validation. If `getSettingValue` returns an unexpected type (e.g., String instead of Integer), this could cause runtime ClassCastException when the value is later unboxed to `int` in `AstBuilder.visitRexCommand`. api/src/main/java/org/opensearch/sql/api/UnifiedQueryContext.java [251-256] if (liveSettings != null) { Object liveRexLimit = liveSettings.getSettingValue(PPL_REX_MAX_MATCH_LIMIT); - if (liveRexLimit != null) { + if (liveRexLimit instanceof Integer) { settings.put(PPL_REX_MAX_MATCH_LIMIT, liveRexLimit); } } Suggestion importance[1-10]: 7 __ Why: Valid concern about type safety. The code retrieves `liveRexLimit` as `Object` and stores it without validation. Adding an `instanceof Integer` check prevents potential `ClassCastException` when the value is later unboxed to `int` in `AstBuilder.visitRexCommand`. However, this is defensive programming rather than fixing a critical bug, as the `Settings` implementation should return the correct type.	Medium

Suggestions up to commit 62d617d

Category	Suggestion	Impact
Possible issue	Validate type before storing setting value The code retrieves `liveRexLimit` as `Object` but doesn't validate its type before putting it into the settings map. If `getSettingValue` returns an unexpected type, downstream code expecting an `int` (as mentioned in the javadoc about unboxing) could fail with a `ClassCastException`. api/src/main/java/org/opensearch/sql/api/UnifiedQueryContext.java [251-256] if (liveSettings != null) { Object liveRexLimit = liveSettings.getSettingValue(PPL_REX_MAX_MATCH_LIMIT); - if (liveRexLimit != null) { + if (liveRexLimit instanceof Integer) { settings.put(PPL_REX_MAX_MATCH_LIMIT, liveRexLimit); } } Suggestion importance[1-10]: 7 __ Why: The suggestion correctly identifies a potential type safety issue where `liveRexLimit` is retrieved as `Object` without type validation. While the javadoc mentions unboxing to `int`, adding an `instanceof Integer` check would prevent potential `ClassCastException` downstream. However, this is defensive programming rather than fixing a critical bug, as the setting system likely returns the correct type.	Medium

Suggestions up to commit 0f1c8ce

Category	Suggestion	Impact
General	Extract hardcoded default to constant The hardcoded value `10` for `PPL_REX_MAX_MATCH_LIMIT` creates a maintenance burden and potential inconsistency if the default changes elsewhere. Consider extracting this default value to a constant in `SysLimit` or the settings definition class, similar to how other limits are accessed via `SysLimit.DEFAULT`. api/src/main/java/org/opensearch/sql/api/UnifiedQueryContext.java [135-142] private final Map<Settings.Key, Object> settings = new HashMap<Settings.Key, Object>( Map.of( QUERY_SIZE_LIMIT, SysLimit.DEFAULT.querySizeLimit(), PPL_SUBSEARCH_MAXOUT, SysLimit.DEFAULT.subsearchLimit(), PPL_JOIN_SUBSEARCH_MAXOUT, SysLimit.DEFAULT.joinSubsearchLimit(), CALCITE_ENGINE_ENABLED, true, - PPL_REX_MAX_MATCH_LIMIT, 10)); + PPL_REX_MAX_MATCH_LIMIT, SysLimit.DEFAULT.rexMaxMatchLimit())); Suggestion importance[1-10]: 7 __ Why: The suggestion correctly identifies that hardcoding `10` for `PPL_REX_MAX_MATCH_LIMIT` creates maintenance burden. Extracting to a constant like `SysLimit.DEFAULT.rexMaxMatchLimit()` would improve consistency with other limits and make future changes easier. However, this is a code quality improvement rather than a critical bug fix.	Medium

github-actions · 2026-05-07T21:30:35Z

Persistent review updated to latest commit 0f1c8ce

…dge-only Onboards the PPL `rex` command's `mode=sed` surface — the part that lowers to standard Calcite library operators and bridges through Substrait to DataFusion's native UDFs. Three sed sub-variants covered: * `rex field=f mode=sed "s/old/new/"` (no flags) → SqlLibraryOperators.REGEXP_REPLACE_3 (already mapped via the PPL `replace` onboarding from opensearch-project#21527 — no-op here). * `rex field=f mode=sed "s/old/new/g"` / `/i` / `/gi` → SqlLibraryOperators.REGEXP_REPLACE_PG_4 (4-arg with flags string). New bridge in this PR. DataFusion's regexp_replace natively accepts 4-arg `(str, pat, repl, flags)` per its substrait UDF binding. * `rex field=f mode=sed "y/from/to/"` (transliteration) → SqlLibraryOperators.TRANSLATE3. New bridge in this PR. Resolves to DataFusion's `translate` UDF (datafusion-functions/src/unicode/translate.rs). ## Why an adapter extension is necessary The 4-arg `REGEXP_REPLACE_PG_4` carries the same Java-regex syntax baggage as the 3-arg form: `\Q…\E` quoted-literal blocks (Rust regex rejects them) and bare `$N` backreferences in the replacement (Rust's identifier-greedy parser mis-resolves them). RegexpReplaceAdapter, introduced for the 3-arg form in opensearch-project#21527, is extended here to recognize 3 OR 4 operands. Pattern is at position 1 and replacement at position 2 in both signatures — the rewrite logic doesn't change. Operands beyond position 2 (the flags string in the 4-arg form) pass through verbatim. Two new RegexpReplaceAdapterTests cover the 4-arg path. `TRANSLATE3` doesn't need an adapter — its arguments are character classes, not regex syntax. ## Out of scope (deferred to Part 2) * Rex extract mode (`rex field=f "(?<g>...)"`) — uses the SQL plugin's custom Java UDFs `REX_EXTRACT`, `REX_EXTRACT_MULTI`, `REX_OFFSET`, which have no native DataFusion equivalent. Slated for a follow-up PR that adds Rust-side UDF implementations, similar to the convert_tz precedent (opensearch-project#21476). * Sed with occurrence flag (`s/.../.../<N>`) — emits 5-arg `REGEXP_REPLACE_5`, which DataFusion's native `regexp_replace` does not support (max 4 args). Also Part 2. ## Test results * `RegexpReplaceAdapterTests` — 21/21 (19 from opensearch-project#21527 + 2 new for the 4-arg path). * `RexCommandIT` (new self-contained QA IT, calcs dataset) — 9/9. Covers all sed sub-variants: literal (no flags), `/g` global, `/i` case-insensitive, `/gi` combined, backreferences via `$N`, transliteration `y/from/to/` and no-match passthrough. * `./gradlew check -p sandbox -Dsandbox.enabled=true` — green. ## Companion PR The unified-path NPE caused by a missing PPL_REX_MAX_MATCH_LIMIT default is fixed in opensearch-project/sql#5418 — required for any rex query (sed or extract) to reach the planner via /_analytics/ppl. This PR's Test results assume opensearch-project#5418 is applied. Pre-fix: every query NPEs in `AstBuilder.visitRexCommand`. Post-fix: 9/9 RexCommandIT pass. Signed-off-by: Jialiang Liang <jiallian@amazon.com>

github-actions · 2026-05-08T02:15:49Z

Persistent review updated to latest commit 62d617d

github-actions · 2026-05-08T02:31:56Z

Persistent review updated to latest commit e46eaa0

The PPL `rex` command's AstBuilder reads `Settings.Key.PPL_REX_MAX_MATCH_LIMIT` unconditionally and unboxes the result to `int`: int maxMatchLimit = (settings != null) ? settings.getSettingValue(...) : 10; The `(settings != null)` guard only protects against the Settings instance being null — not against `getSettingValue` returning null for a key that the caller never registered. On the unified query path, `UnifiedQueryContext` builds its `Settings` map with only a small whitelist of keys (e.g. `QUERY_SIZE_LIMIT`, `CALCITE_ENGINE_ENABLED` per opensearch-project#5413). For any unregistered key, `getSettingValue` returns null, and the auto-unbox NPEs the planner before any operator-level capability check runs. Every `rex` query through `/_analytics/ppl` (the analytics-engine route's REST front-end) hits this NPE today. Default `PPL_REX_MAX_MATCH_LIMIT=10` in `buildSettings()` so unified-path behavior matches the cluster-side default registered by `OpenSearchSettings.PPL_REX_MAX_MATCH_LIMIT_SETTING` — making the v2 path and the analytics-engine path agree on the same fallback value when neither has an explicit cluster override. Mirrors the precedent Kai introduced for `CALCITE_ENGINE_ENABLED` in opensearch-project#5413. Companion to the OpenSearch core PR onboarding PPL `rex mode=sed` to the analytics-engine route via DataFusion (Part 1 — sed-mode bridge only; extract-mode Rust UDFs deferred to Part 2). Signed-off-by: Jialiang Liang <jiallian@amazon.com>

github-actions · 2026-05-08T02:53:08Z

Persistent review updated to latest commit 6d0dc2c

github-actions · 2026-05-08T03:32:28Z

Persistent review updated to latest commit c655e4a

… setting() API The previous commit defaulted `PPL_REX_MAX_MATCH_LIMIT=10` in `UnifiedQueryContext.Builder.settings` to fix the NPE in `AstBuilder.visitRexCommand` on the unified path. The default is correct, but it doesn't respect mid-run cluster overrides — every key in the static map returns its hardcoded value regardless of `_cluster/settings` updates. This breaks `CalciteRexCommandIT.testRexMaxMatchConfigurableLimit`, which sets the cluster-side limit to 5 and asserts `max_match=0` caps at 5; on the unified path it stayed at 10. Rather than introducing a new `Settings`-typed Builder API, the REST handler reads the live cluster value itself and routes it through the existing `Builder.setting(String, Object)` method — keeping `UnifiedQueryContext` decoupled from any specific `Settings` implementation: RestUnifiedQueryAction.applyClusterOverrides(builder) └── pluginSettings.getSettingValue(PPL_REX_MAX_MATCH_LIMIT) └── builder.setting("plugins.ppl.rex.max_match.limit", value) `RestUnifiedQueryAction` gains a `pluginSettings` field (the same `OpenSearchSettings` instance bound in the Guice module). Both construction sites — `SQLPlugin.createSqlAnalyticsRouter` and `TransportPPLQueryAction.<init>` — pass it through. `RestUnifiedQueryActionTest` updated to pass a `mock(Settings.class)` for the new constructor parameter. ## Why scoped to PPL_REX_MAX_MATCH_LIMIT only The same architectural gap exists for every key in the static defaults map (`QUERY_SIZE_LIMIT`, `PPL_SUBSEARCH_MAXOUT`, `PPL_JOIN_SUBSEARCH_MAXOUT`, `CALCITE_ENGINE_ENABLED`). For three of those, the static defaults are fine in practice (no test overrides them mid-run; `head N` covers `QUERY_SIZE_LIMIT` per-query). `CALCITE_ENGINE_ENABLED` is intentionally pinned to `true` for the unified path. So this PR widens only the one key that demonstrably needs it; widening the snapshot to the rest is a future scope decision tied to whichever new IT first depends on it. Signed-off-by: Jialiang Liang <jiallian@amazon.com>

Pins two behaviors the previous commits introduced: * `testContextCreationWithDefaults` now asserts that `PPL_REX_MAX_MATCH_LIMIT` resolves to its static default of 10 — the fallback value `AstBuilder.visitRexCommand` reads when no cluster-side override is present. * `testContextCreationWithCustomConfig` now asserts that `setting("plugins.ppl.rex.max_match.limit", 5)` reaches `getSettingValue(PPL_REX_MAX_MATCH_LIMIT)` — the path the REST handler uses to forward an operator-configured cluster value into the unified-path settings map. Folds the two assertions into the existing default / custom-config tests rather than adding new test methods, per review feedback. Signed-off-by: Jialiang Liang <jiallian@amazon.com>

github-actions · 2026-05-08T05:24:36Z

Persistent review updated to latest commit aa0ae82

…dge-only Onboards the PPL `rex` command's `mode=sed` surface — the part that lowers to standard Calcite library operators and bridges through Substrait to DataFusion's native UDFs. Three sed sub-variants covered: * `rex field=f mode=sed "s/old/new/"` (no flags) → SqlLibraryOperators.REGEXP_REPLACE_3 (already mapped via the PPL `replace` onboarding from opensearch-project#21527 — no-op here). * `rex field=f mode=sed "s/old/new/g"` / `/i` / `/gi` → SqlLibraryOperators.REGEXP_REPLACE_PG_4 (4-arg with flags string). New bridge in this PR. DataFusion's regexp_replace natively accepts 4-arg `(str, pat, repl, flags)` per its substrait UDF binding. * `rex field=f mode=sed "y/from/to/"` (transliteration) → SqlLibraryOperators.TRANSLATE3. New bridge in this PR. Resolves to DataFusion's `translate` UDF (datafusion-functions/src/unicode/translate.rs). The 4-arg `REGEXP_REPLACE_PG_4` carries the same Java-regex syntax baggage as the 3-arg form: `\Q…\E` quoted-literal blocks (Rust regex rejects them) and bare `$N` backreferences in the replacement (Rust's identifier-greedy parser mis-resolves them). RegexpReplaceAdapter, introduced for the 3-arg form in and replacement at position 2 in both signatures — the rewrite logic doesn't change. Operands beyond position 2 (the flags string in the 4-arg form) pass through verbatim. Two new RegexpReplaceAdapterTests cover the 4-arg path. `TRANSLATE3` doesn't need an adapter — its arguments are character classes, not regex syntax. * Rex extract mode (`rex field=f "(?<g>...)"`) — uses the SQL plugin's custom Java UDFs `REX_EXTRACT`, `REX_EXTRACT_MULTI`, `REX_OFFSET`, which have no native DataFusion equivalent. Slated for a follow-up PR that adds Rust-side UDF implementations, similar to the convert_tz precedent (opensearch-project#21476). * Sed with occurrence flag (`s/.../.../<N>`) — emits 5-arg `REGEXP_REPLACE_5`, which DataFusion's native `regexp_replace` does not support (max 4 args). Also Part 2. * `RegexpReplaceAdapterTests` — 21/21 (19 from opensearch-project#21527 + 2 new for the 4-arg path). * `RexCommandIT` (new self-contained QA IT, calcs dataset) — 9/9. Covers all sed sub-variants: literal (no flags), `/g` global, `/i` case-insensitive, `/gi` combined, backreferences via `$N`, transliteration `y/from/to/` and no-match passthrough. * `./gradlew check -p sandbox -Dsandbox.enabled=true` — green. The unified-path NPE caused by a missing PPL_REX_MAX_MATCH_LIMIT default is fixed in opensearch-project/sql#5418 — required for any rex query (sed or extract) to reach the planner via /_analytics/ppl. This PR's Test results assume opensearch-project#5418 is applied. Pre-fix: every query NPEs in `AstBuilder.visitRexCommand`. Post-fix: 9/9 RexCommandIT pass. Signed-off-by: Jialiang Liang <jiallian@amazon.com>

@ignore

Single squashed delivery of the long-running feature/mustang-ppl-integration branch into main, consolidating 22 feature-branch PRs plus the conflict-resolved merge of current main. Squashed because the feature branch's history includes commits with missing or mismatched Signed-off-by trailers that block DCO at this scope — the equivalent issue documented for the catch-up squashes (opensearch-project#5397). The feature branch f006e29 is retained for individual-commit lineage. ### What this delivers Analytics-engine PPL integration — a new execution path that routes Parquet-backed (non-Lucene) indices through an analytics engine while keeping Lucene-backed indices on the existing v2 / Calcite paths. Headline pieces: - Query routing (opensearch-project#5267) — PPL queries against Parquet-backed indices hand off to the analytics-engine execution path; Lucene-backed indices continue through the legacy path - Explain support (opensearch-project#5275) — EXPLAIN covers the analytics-engine path - Profiling + UnifiedQueryParser (opensearch-project#5285) — migrates PPL parsing to the unified parser and wires profiling metrics through the analytics path - extendedPlugins wiring (opensearch-project#5302) — analytics-engine attaches as an OpenSearch extension via SPI - SQL REST endpoint integration (opensearch-project#5317) — same analytics-route fork applied to the SQL transport, plus delegateToV2Engine extraction in RestSqlAction - Async QueryPlanExecutor (opensearch-project#5396) — async execution for analytics-engine plans + version bump to OpenSearch 3.7 - Optional dependency (opensearch-project#5403) — analytics-engine becomes an optional runtime dep so the SQL bundle is shippable without it - Index-setting-based routing (opensearch-project#5429) — replaces the earlier table-name-prefix heuristic with an authoritative index-setting check Supporting infrastructure: - Gradle wrapper bump to 9.4.1 (opensearch-project#5406) - Jar-hell exclusions for arrow-flight-rpc / httpcore5-h2 / httpcore5-reactive / httpclient5 (opensearch-project#5400, opensearch-project#5409) - IT plumbing: CalciteEvalCommandIT / CalciteFieldFormatCommandIT carried through the helper-managed index path (opensearch-project#5407, opensearch-project#5417); CalciteReplaceCommandIT column-order-agnostic (opensearch-project#5415); @ignore'd Calcite ITs dropped from CalciteNoPushdownIT (opensearch-project#5416) - plugins.calcite.enabled=true defaulted on the unified query path (opensearch-project#5413) - PPL_REX_MAX_MATCH_LIMIT bridged into UnifiedQueryContext (opensearch-project#5418) - Calcite tolerance fixes: array() default type (opensearch-project#5421), containsNestedAggregator flat-leaf schemas (opensearch-project#5423) - Sandbox deps switched to analytics-api JDK 21 surface (opensearch-project#5426) ### Feature-branch commits squashed (22) opensearch-project#5429, opensearch-project#5426, opensearch-project#5423, opensearch-project#5421, opensearch-project#5418, opensearch-project#5403, opensearch-project#5417, opensearch-project#5415, opensearch-project#5416, opensearch-project#5413, opensearch-project#5407, opensearch-project#5409, opensearch-project#5406, opensearch-project#5400, opensearch-project#5396, opensearch-project#5317, opensearch-project#5302, opensearch-project#5285, opensearch-project#5275, opensearch-project#5267, opensearch-project#5397, opensearch-project#5286 ### Main commits absorbed via the merge (54) Brings the branch up to current upstream/main (54 commits since the last catch-up at opensearch-project#5397, divergence point 513e1b2). Highlights: opensearch-project#5419, opensearch-project#5408, opensearch-project#5414, opensearch-project#5399, opensearch-project#5394, opensearch-project#5361, opensearch-project#5360, opensearch-project#5240, opensearch-project#5266, opensearch-project#5278, plus 44 others (bugfixes, doc updates, infra). ### Conflict resolutions (7) Resolved during the merge of main into the feature branch. Resolution kept the feature branch's analytics-engine-path semantics where main's changes would have regressed them. - api/.../UnifiedQueryContext.java Blank-line-only conflict; took main's tighter formatting. - core/.../executor/QueryService.java Kept feature's CalciteClassLoaderHelper.withCalciteClassLoader(...) wrapping (required for analytics-engine classloader isolation) and the matching import. - integ-test/build.gradle Kept feature's detailed root-cause comment on the Gradle 9.4.1 TestEventReporterAsListener workaround; kept ASCII ordering of JSONRequestIT / JoinIT and SQLFunctionsIT / ShowIT / SourceFieldIT entries. - integ-test/.../CalciteEvalCommandIT.java Kept feature's if (!TestUtils.isIndexExist(...)) idempotency guards on test_eval and test_eval_agent setup (needed for the helper-managed index analytics-engine compatibility run). - legacy/.../RestSqlAction.java Kept feature's delegateToV2Engine(...) (extracted from the analytics-engine routing path). Both sides added handleException / getRestStatus / getRawErrorCode; removed the duplicate set git produced. - plugin/.../SQLPlugin.java Took the union of imports: ExecutionEngine + ExecutionEngine.ExplainResponse + QueryType. - plugin/.../transport/TransportPPLQueryAction.java Combined main's OpenSearchPluginModule(extensionsHolder.engines()) and feature's local pluginSettings / pluginSettingsRef wiring. EngineExtensionsHolder.java is a new file from main (opensearch-project#5298) preserved as-is. ### Compatibility / opt-in The analytics-engine path is gated by the extendedPlugins extension being installed (opensearch-project#5403 makes the dep optional). Clusters without analytics-engine installed see no behavior change. Clusters with analytics-engine installed route only Parquet-backed indices through the new path (opensearch-project#5429 — by index setting). ### Verification - ./gradlew :api:compileJava :core:compileJava :legacy:compileJava :opensearch-sql-plugin:compileJava :integ-test:compileTestJava passes locally Signed-off-by: Kai Huang <ahkcs@amazon.com>

@ignore

Single squashed delivery of the long-running feature/mustang-ppl-integration branch into main, consolidating 22 feature-branch PRs plus the conflict-resolved merge of current main. Squashed because the feature branch's history includes commits with missing or mismatched Signed-off-by trailers that block DCO at this scope — the equivalent issue documented for the catch-up squashes (opensearch-project#5397). The feature branch f006e29 is retained for individual-commit lineage. ### What this delivers Analytics-engine PPL integration — a new execution path that routes Parquet-backed (non-Lucene) indices through an analytics engine while keeping Lucene-backed indices on the existing v2 / Calcite paths. Headline pieces: - Query routing (opensearch-project#5267) — PPL queries against Parquet-backed indices hand off to the analytics-engine execution path; Lucene-backed indices continue through the legacy path - Explain support (opensearch-project#5275) — EXPLAIN covers the analytics-engine path - Profiling + UnifiedQueryParser (opensearch-project#5285) — migrates PPL parsing to the unified parser and wires profiling metrics through the analytics path - extendedPlugins wiring (opensearch-project#5302) — analytics-engine attaches as an OpenSearch extension via SPI - SQL REST endpoint integration (opensearch-project#5317) — same analytics-route fork applied to the SQL transport, plus delegateToV2Engine extraction in RestSqlAction - Async QueryPlanExecutor (opensearch-project#5396) — async execution for analytics-engine plans + version bump to OpenSearch 3.7 - Optional dependency (opensearch-project#5403) — analytics-engine becomes an optional runtime dep so the SQL bundle is shippable without it - Index-setting-based routing (opensearch-project#5429, opensearch-project#5432) — replaces the earlier table-name-prefix heuristic with an authoritative index-setting check Supporting infrastructure: - Gradle wrapper bump to 9.4.1 (opensearch-project#5406) - Jar-hell exclusions for arrow-flight-rpc / httpcore5-h2 / httpcore5-reactive / httpclient5 (opensearch-project#5400, opensearch-project#5409) - IT plumbing: CalciteEvalCommandIT / CalciteFieldFormatCommandIT carried through the helper-managed index path (opensearch-project#5407, opensearch-project#5417); CalciteReplaceCommandIT column-order-agnostic (opensearch-project#5415); @ignore'd Calcite ITs dropped from CalciteNoPushdownIT (opensearch-project#5416) - plugins.calcite.enabled=true defaulted on the unified query path (opensearch-project#5413) - PPL_REX_MAX_MATCH_LIMIT bridged into UnifiedQueryContext (opensearch-project#5418) - Calcite tolerance fixes: array() default type (opensearch-project#5421), containsNestedAggregator flat-leaf schemas (opensearch-project#5423) - Sandbox deps switched to analytics-api JDK 21 surface (opensearch-project#5426) ### Feature-branch commits squashed (22) opensearch-project#5432, opensearch-project#5429, opensearch-project#5426, opensearch-project#5423, opensearch-project#5421, opensearch-project#5418, opensearch-project#5403, opensearch-project#5417, opensearch-project#5415, opensearch-project#5416, opensearch-project#5413, opensearch-project#5407, opensearch-project#5409, opensearch-project#5406, opensearch-project#5400, opensearch-project#5396, opensearch-project#5317, opensearch-project#5302, opensearch-project#5285, opensearch-project#5275, opensearch-project#5267, opensearch-project#5397, opensearch-project#5286 ### Main commits absorbed via the merge (54) Brings the branch up to current upstream/main (54 commits since the last catch-up at opensearch-project#5397, divergence point 513e1b2). Highlights: opensearch-project#5419, opensearch-project#5408, opensearch-project#5414, opensearch-project#5399, opensearch-project#5394, opensearch-project#5361, opensearch-project#5360, opensearch-project#5240, opensearch-project#5266, opensearch-project#5278, plus 44 others (bugfixes, doc updates, infra). ### Conflict resolutions (7) Resolved during the merge of main into the feature branch. Resolution kept the feature branch's analytics-engine-path semantics where main's changes would have regressed them. - api/.../UnifiedQueryContext.java Blank-line-only conflict; took main's tighter formatting. - core/.../executor/QueryService.java Kept feature's CalciteClassLoaderHelper.withCalciteClassLoader(...) wrapping (required for analytics-engine classloader isolation) and the matching import. - integ-test/build.gradle Kept feature's detailed root-cause comment on the Gradle 9.4.1 TestEventReporterAsListener workaround; kept ASCII ordering of JSONRequestIT / JoinIT and SQLFunctionsIT / ShowIT / SourceFieldIT entries. - integ-test/.../CalciteEvalCommandIT.java Kept feature's if (!TestUtils.isIndexExist(...)) idempotency guards on test_eval and test_eval_agent setup (needed for the helper-managed index analytics-engine compatibility run). - legacy/.../RestSqlAction.java Kept feature's delegateToV2Engine(...) (extracted from the analytics-engine routing path). Both sides added handleException / getRestStatus / getRawErrorCode; removed the duplicate set git produced. - plugin/.../SQLPlugin.java Took the union of imports: ExecutionEngine + ExecutionEngine.ExplainResponse + QueryType. - plugin/.../transport/TransportPPLQueryAction.java Combined main's OpenSearchPluginModule(extensionsHolder.engines()) and feature's local pluginSettings / pluginSettingsRef wiring. EngineExtensionsHolder.java is a new file from main (opensearch-project#5298) preserved as-is. ### Compatibility / opt-in The analytics-engine path is gated by the extendedPlugins extension being installed (opensearch-project#5403 makes the dep optional). Clusters without analytics-engine installed see no behavior change. Clusters with analytics-engine installed route only Parquet-backed indices through the new path (opensearch-project#5429 — by index setting). ### Verification - ./gradlew :api:compileJava :core:compileJava :legacy:compileJava :opensearch-sql-plugin:compileJava :integ-test:compileTestJava passes locally Signed-off-by: Kai Huang <ahkcs@amazon.com> Co-authored-by: bowenlan-amzn <bowenlan23@gmail.com>

@ignore

* Land analytics-engine PPL integration into main Single squashed delivery of the long-running feature/mustang-ppl-integration branch into main, consolidating 22 feature-branch PRs plus the conflict-resolved merge of current main. Squashed because the feature branch's history includes commits with missing or mismatched Signed-off-by trailers that block DCO at this scope — the equivalent issue documented for the catch-up squashes (#5397). The feature branch f006e29 is retained for individual-commit lineage. ### What this delivers Analytics-engine PPL integration — a new execution path that routes Parquet-backed (non-Lucene) indices through an analytics engine while keeping Lucene-backed indices on the existing v2 / Calcite paths. Headline pieces: - Query routing (#5267) — PPL queries against Parquet-backed indices hand off to the analytics-engine execution path; Lucene-backed indices continue through the legacy path - Explain support (#5275) — EXPLAIN covers the analytics-engine path - Profiling + UnifiedQueryParser (#5285) — migrates PPL parsing to the unified parser and wires profiling metrics through the analytics path - extendedPlugins wiring (#5302) — analytics-engine attaches as an OpenSearch extension via SPI - SQL REST endpoint integration (#5317) — same analytics-route fork applied to the SQL transport, plus delegateToV2Engine extraction in RestSqlAction - Async QueryPlanExecutor (#5396) — async execution for analytics-engine plans + version bump to OpenSearch 3.7 - Optional dependency (#5403) — analytics-engine becomes an optional runtime dep so the SQL bundle is shippable without it - Index-setting-based routing (#5429, #5432) — replaces the earlier table-name-prefix heuristic with an authoritative index-setting check Supporting infrastructure: - Gradle wrapper bump to 9.4.1 (#5406) - Jar-hell exclusions for arrow-flight-rpc / httpcore5-h2 / httpcore5-reactive / httpclient5 (#5400, #5409) - IT plumbing: CalciteEvalCommandIT / CalciteFieldFormatCommandIT carried through the helper-managed index path (#5407, #5417); CalciteReplaceCommandIT column-order-agnostic (#5415); @ignore'd Calcite ITs dropped from CalciteNoPushdownIT (#5416) - plugins.calcite.enabled=true defaulted on the unified query path (#5413) - PPL_REX_MAX_MATCH_LIMIT bridged into UnifiedQueryContext (#5418) - Calcite tolerance fixes: array() default type (#5421), containsNestedAggregator flat-leaf schemas (#5423) - Sandbox deps switched to analytics-api JDK 21 surface (#5426) ### Feature-branch commits squashed (22) #5432, #5429, #5426, #5423, #5421, #5418, #5403, #5417, #5415, #5416, #5413, #5407, #5409, #5406, #5400, #5396, #5317, #5302, #5285, #5275, #5267, #5397, #5286 ### Main commits absorbed via the merge (54) Brings the branch up to current upstream/main (54 commits since the last catch-up at #5397, divergence point 513e1b2). Highlights: #5419, #5408, #5414, #5399, #5394, #5361, #5360, #5240, #5266, #5278, plus 44 others (bugfixes, doc updates, infra). ### Conflict resolutions (7) Resolved during the merge of main into the feature branch. Resolution kept the feature branch's analytics-engine-path semantics where main's changes would have regressed them. - api/.../UnifiedQueryContext.java Blank-line-only conflict; took main's tighter formatting. - core/.../executor/QueryService.java Kept feature's CalciteClassLoaderHelper.withCalciteClassLoader(...) wrapping (required for analytics-engine classloader isolation) and the matching import. - integ-test/build.gradle Kept feature's detailed root-cause comment on the Gradle 9.4.1 TestEventReporterAsListener workaround; kept ASCII ordering of JSONRequestIT / JoinIT and SQLFunctionsIT / ShowIT / SourceFieldIT entries. - integ-test/.../CalciteEvalCommandIT.java Kept feature's if (!TestUtils.isIndexExist(...)) idempotency guards on test_eval and test_eval_agent setup (needed for the helper-managed index analytics-engine compatibility run). - legacy/.../RestSqlAction.java Kept feature's delegateToV2Engine(...) (extracted from the analytics-engine routing path). Both sides added handleException / getRestStatus / getRawErrorCode; removed the duplicate set git produced. - plugin/.../SQLPlugin.java Took the union of imports: ExecutionEngine + ExecutionEngine.ExplainResponse + QueryType. - plugin/.../transport/TransportPPLQueryAction.java Combined main's OpenSearchPluginModule(extensionsHolder.engines()) and feature's local pluginSettings / pluginSettingsRef wiring. EngineExtensionsHolder.java is a new file from main (#5298) preserved as-is. ### Compatibility / opt-in The analytics-engine path is gated by the extendedPlugins extension being installed (#5403 makes the dep optional). Clusters without analytics-engine installed see no behavior change. Clusters with analytics-engine installed route only Parquet-backed indices through the new path (#5429 — by index setting). ### Verification - ./gradlew :api:compileJava :core:compileJava :legacy:compileJava :opensearch-sql-plugin:compileJava :integ-test:compileTestJava passes locally Signed-off-by: Kai Huang <ahkcs@amazon.com> Co-authored-by: bowenlan-amzn <bowenlan23@gmail.com> * Address @penghuo: revert stray blank line in doctest/build.gradle After 'apply plugin: opensearch.testclusters', one blank line is enough — restoring the single-blank spacing to match upstream/main. Signed-off-by: Kai Huang <ahkcs@amazon.com> --------- Signed-off-by: Kai Huang <ahkcs@amazon.com> Co-authored-by: bowenlan-amzn <bowenlan23@gmail.com>

…dge-only Onboards the PPL `rex` command's `mode=sed` surface — the part that lowers to standard Calcite library operators and bridges through Substrait to DataFusion's native UDFs. Three sed sub-variants covered: * `rex field=f mode=sed "s/old/new/"` (no flags) → SqlLibraryOperators.REGEXP_REPLACE_3 (already mapped via the PPL `replace` onboarding from opensearch-project#21527 — no-op here). * `rex field=f mode=sed "s/old/new/g"` / `/i` / `/gi` → SqlLibraryOperators.REGEXP_REPLACE_PG_4 (4-arg with flags string). New bridge in this PR. DataFusion's regexp_replace natively accepts 4-arg `(str, pat, repl, flags)` per its substrait UDF binding. * `rex field=f mode=sed "y/from/to/"` (transliteration) → SqlLibraryOperators.TRANSLATE3. New bridge in this PR. Resolves to DataFusion's `translate` UDF (datafusion-functions/src/unicode/translate.rs). The 4-arg `REGEXP_REPLACE_PG_4` carries the same Java-regex syntax baggage as the 3-arg form: `\Q…\E` quoted-literal blocks (Rust regex rejects them) and bare `$N` backreferences in the replacement (Rust's identifier-greedy parser mis-resolves them). RegexpReplaceAdapter, introduced for the 3-arg form in and replacement at position 2 in both signatures — the rewrite logic doesn't change. Operands beyond position 2 (the flags string in the 4-arg form) pass through verbatim. Two new RegexpReplaceAdapterTests cover the 4-arg path. `TRANSLATE3` doesn't need an adapter — its arguments are character classes, not regex syntax. * Rex extract mode (`rex field=f "(?<g>...)"`) — uses the SQL plugin's custom Java UDFs `REX_EXTRACT`, `REX_EXTRACT_MULTI`, `REX_OFFSET`, which have no native DataFusion equivalent. Slated for a follow-up PR that adds Rust-side UDF implementations, similar to the convert_tz precedent (opensearch-project#21476). * Sed with occurrence flag (`s/.../.../<N>`) — emits 5-arg `REGEXP_REPLACE_5`, which DataFusion's native `regexp_replace` does not support (max 4 args). Also Part 2. * `RegexpReplaceAdapterTests` — 21/21 (19 from opensearch-project#21527 + 2 new for the 4-arg path). * `RexCommandIT` (new self-contained QA IT, calcs dataset) — 9/9. Covers all sed sub-variants: literal (no flags), `/g` global, `/i` case-insensitive, `/gi` combined, backreferences via `$N`, transliteration `y/from/to/` and no-match passthrough. * `./gradlew check -p sandbox -Dsandbox.enabled=true` — green. The unified-path NPE caused by a missing PPL_REX_MAX_MATCH_LIMIT default is fixed in opensearch-project/sql#5418 — required for any rex query (sed or extract) to reach the planner via /_analytics/ppl. This PR's Test results assume opensearch-project#5418 is applied. Pre-fix: every query NPEs in `AstBuilder.visitRexCommand`. Post-fix: 9/9 RexCommandIT pass. Signed-off-by: Jialiang Liang <jiallian@amazon.com>

RyanL1997 requested review from LantaoJin, Swiddis, acarbonetto, ahkcs, anirudha, dai-chen, joshuali925, mengweieric, noCharger, penghuo, ps48, qianheng-aws, songkant-aws, vamsimanohar, ykmr1224 and yuancu as code owners May 7, 2026 21:04

RyanL1997 mentioned this pull request May 7, 2026

[Analytics Backend / DataFusion] Onboard PPL rex to DataFusion opensearch-project/OpenSearch#21550

Open

RyanL1997 force-pushed the mustang-rex-unified-default branch from 95521c9 to 0f1c8ce Compare May 7, 2026 21:29

RyanL1997 added the PPL Piped processing language label May 7, 2026

RyanL1997 added the feature label May 7, 2026

ahkcs approved these changes May 7, 2026

View reviewed changes

RyanL1997 changed the title ~~Default plugins.ppl.rex.max_match.limit=10 on the unified query path~~ Bridge PPL_REX_MAX_MATCH_LIMIT into UnifiedQueryContext on the unified query path May 8, 2026

RyanL1997 force-pushed the mustang-rex-unified-default branch from e46eaa0 to 6d0dc2c Compare May 8, 2026 02:51

penghuo reviewed May 8, 2026

View reviewed changes

Comment thread api/src/main/java/org/opensearch/sql/api/UnifiedQueryContext.java Outdated

Comment thread api/src/main/java/org/opensearch/sql/api/UnifiedQueryContext.java Outdated

RyanL1997 force-pushed the mustang-rex-unified-default branch from 6d0dc2c to c655e4a Compare May 8, 2026 03:31

RyanL1997 added enhancement New feature or request and removed feature labels May 8, 2026

penghuo approved these changes May 8, 2026

View reviewed changes

dai-chen reviewed May 8, 2026

View reviewed changes

Comment thread api/src/main/java/org/opensearch/sql/api/UnifiedQueryContext.java Outdated

Comment thread api/src/main/java/org/opensearch/sql/api/UnifiedQueryContext.java Outdated

dai-chen reviewed May 8, 2026

View reviewed changes

Comment thread api/src/test/java/org/opensearch/sql/api/UnifiedQueryContextTest.java Outdated

RyanL1997 added 2 commits May 7, 2026 22:23

RyanL1997 force-pushed the mustang-rex-unified-default branch from c655e4a to aa0ae82 Compare May 8, 2026 05:23

dai-chen approved these changes May 8, 2026

View reviewed changes

RyanL1997 merged commit d481e0b into opensearch-project:feature/mustang-ppl-integration May 8, 2026
54 of 57 checks passed

RyanL1997 deleted the mustang-rex-unified-default branch May 8, 2026 16:42

This was referenced May 11, 2026

Land analytics-engine PPL integration into main #5431

Closed

Land analytics-engine PPL integration into main #5430

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Bridge PPL_REX_MAX_MATCH_LIMIT into UnifiedQueryContext on the unified query path#5418

Bridge PPL_REX_MAX_MATCH_LIMIT into UnifiedQueryContext on the unified query path#5418
RyanL1997 merged 3 commits into
opensearch-project:feature/mustang-ppl-integrationfrom
RyanL1997:mustang-rex-unified-default

RyanL1997 commented May 7, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented May 7, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented May 7, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented May 7, 2026

Uh oh!

github-actions Bot commented May 8, 2026

Uh oh!

github-actions Bot commented May 8, 2026

Uh oh!

github-actions Bot commented May 8, 2026

Uh oh!

Uh oh!

Uh oh!

github-actions Bot commented May 8, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

github-actions Bot commented May 8, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

RyanL1997 commented May 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

1. Default PPL_REX_MAX_MATCH_LIMIT=10 in UnifiedQueryContext

2. Bridge live cluster settings for PPL_REX_MAX_MATCH_LIMIT only

Why scoped to PPL_REX_MAX_MATCH_LIMIT only

Companion PR

Test results

Uh oh!

github-actions Bot commented May 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Reviewer Guide 🔍

(Review updated until commit aa0ae82)

Uh oh!

github-actions Bot commented May 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Code Suggestions ✨

Previous suggestions

Uh oh!

github-actions Bot commented May 7, 2026

Uh oh!

github-actions Bot commented May 8, 2026

Uh oh!

github-actions Bot commented May 8, 2026

Uh oh!

github-actions Bot commented May 8, 2026

Uh oh!

Uh oh!

Uh oh!

github-actions Bot commented May 8, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

github-actions Bot commented May 8, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

RyanL1997 commented May 7, 2026 •

edited

Loading

1. Default `PPL_REX_MAX_MATCH_LIMIT=10` in `UnifiedQueryContext`

2. Bridge live cluster settings for `PPL_REX_MAX_MATCH_LIMIT` only

Why scoped to `PPL_REX_MAX_MATCH_LIMIT` only

github-actions Bot commented May 7, 2026 •

edited

Loading

(Review updated until commit `aa0ae82`)

github-actions Bot commented May 7, 2026 •

edited

Loading